1. Field of the Invention
The present invention is directed toward the field of rule compliance systems, and more particularly to a rules compliance system that integrates a memory database with a rules definition language.
2. Art Background
In general, xe2x80x9crulesxe2x80x9d are implemented in compliance systems to check parameters or data input to the system. Compliance systems have application for use in analytic systems, including a variety of risk management and surveillance technologies. Compliance systems also have application for use in securities trading. In general, in securities trading, there are a number of rules imposed by regulators (i.e., Securities and Exchange Commission) regarding trading. For example, institutional investors have regulatory obligations with regard to trading. Furthermore, money managers, such as managers of mutual funds, also have guidelines for securities transactions. A portfolio manager for a large institutional investor may impose specific guidelines or rules regarding the diversification of the portfolio. For example, the institutional investors may wish to limit the amount of securities held for a particular industry, define a minimum trading amount, list securities that are not to be purchased for that institutional investor, etc. In addition, a portfolio owner may impose on a broker a number of limitations regarding the type and quantity of securities for trading.
The rules regarding securities trading and other applications have become so complicated that a computer is required to ensure full compliance. To this end, it is necessary to develop a computer based compliance system that effectively implements complex rules for use in high volume analytic applications. One implementation for enforcing rules includes the use of a server. In this configuration, a client generates a query that includes the data necessary to ascertain the compliance of the rules. In response, the server executes the query by determining whether the parameters of a query are in compliance with the underlying rules. Thus, for this configuration, the compliance server operates similar to a database system, wherein a query is received and an answer (e.g., a compliance report) is generated.
Typically, in client/server database applications, interpretive languages, such as the standard query language (xe2x80x9cSQLxe2x80x9d), are used. In general, query languages provide a general infrastructure to request data stored in the underlying database. Typically, the data is stored in tables in a persistent datastore (e.g., a hard disk drive). To execute the query, code is loaded from the persistent datastore into the computer system memory. Then, the query is interpreted, and the code executes an input/output (xe2x80x9cI/Oxe2x80x9d) operation to the persistent datastore to extract rows of data from database tables. In early compliance engine design, this technique was adequate because the rules were relatively static (i.e., the rules did not change very often), and a persistent datastore was the only available storage medium that could handle the massive amount of data involved in compliance rules applications. However, with increasingly complex compliance rule applications, the SQL server approach is extremely slow because this technique requires extensive I/O access to the persistent datastore. Even with today""s advancements in technology, these I/O transactions result in unacceptable delay for use in compliance engines. Therefore, be traditional database approach is an unacceptable environment for high volume time critical analytic transactions, such as securities trading.
Another approach to compliance engine implementation involves the use of third generational languages, such as C++, and a persistent datastore. The use of third generational languages to check or implement rules results in faster execution than the SQL database approach. Although this approach has adequate performance at run time, it is difficult to update and change the underlying rules. Typically, in compliance applications, such as securities trading, the underlying rules change on a daily basis. To change a rule using a third generational language requires programming the rule into the existing code, and recompiling the new code for subsequent execution at run time. However, this process has some dangerous consequences if errors are introduced into the new code. In addition, this process is slow because the new code must pass through quality assurance checks prior to reuse. For example, if a programming error is introduced as a result of a new rule, the entire compliance engine may be rendered inoperable. In addition, the new code, after compiling and linking, must be implemented on the client""s computer. This may introduce potential compatibility problems. If the client is at a disparate location from the compliance engine provider, the need for continual updates may be an impractical solution. Accordingly, rapid changes in the rules renders the compiled code environment an inadequate solution for most compliance engine applications, including pre-trade compliance applications.
Accordingly, it is desirable to develop a compliance engine that is fast and efficient, so as to eliminate or reduce I/O transactions. It is also desirable to implement a compliance engine that is flexible, so as to allow rapid deployment of new or different underlying rules.
A memory server executes queries to determine compliance with rules. The rules, which comprise computer readable instructions, are loaded into system memory of the server. Also, global datum, for use in executing the query, is loaded into system memory of the server. The global datum consists of parameters or values used to determine compliance with the rules. To determine compliance with the rules, the memory server receives a query. The query contains local datum used to determine compliance of that query with the rules. In response, the local datum is stored in server memory. Thereafter, the query is executed by accessing server memory to utilize the local datum and the global datum, such that the server determines compliance with the rules from the memory of the server. The memory server has application for use in determining compliance for securities trading.
A rule definition language (xe2x80x9cRDLxe2x80x9d) is used to implement a compliance system. The syntax of the RDL permits programming in a manner particularly suitable for compliance checking procedures. In one embodiment, the RDL syntax provides a means to declare local variables. A local variable is used to store query data, in system memory, for temporary use of the data during execution of that query. The RDL syntax also provides a means to declare global variables. A global variable is used to store data, in system memory, for use of the data during execution multiple queries in a session. In other embodiments, the RDL syntax provides a means to declare multi-dimensional associative arrays for accessing the multi-dimensional arrays.